Qualify Customer for Loyalty Tier Based on Purchase or Point Activities

This use case describes the workflow of qualifying a customer for a new loyalty tier when they make a specified number of purchases. Once the purchases have been made, SessionM determines if the purchases have generated enough points to satisfy the purchase behavior ruleset that governs how point-based outcomes are awarded.

Part of configuring a SessionM implementation is the definition of a point economy, which provides the foundation for points-based loyalty programs. The key components of a point economy are point accounts, along with policies that define how points are redeemed and expired. With a point economy configured, a client can then define a tiered loyalty program, which can offer rewards based on purchases. The tiers within the loyalty program allow the client to offer different levels of rewards to its customers, each with benefits that recognize a customer's history of spending and brand engagement.

The provisioning of points to point accounts can happen several ways:

  • Awarded through a campaign.

  • Awarded as an outcome of a transaction or event.

  • Deposited by a customer service representative adding points manually.

This use case features a points-based outcome based on a customer making a specified number of purchase transactions.

Customer Journey

One helpful way of understanding this use case is to consider how it reflects the customer's experience, or journey, in the "real world."

Customer signs up for loyalty program, which generates customer profile in default tier, level 1

Customer learns number of transactions necessary to qualify for next tier, level 2

Customer makes 3 transactions, the number required to qualify for tier level 2

After each transaction, SessionM confirms that it meets economy ruleset; if so, it awards points customer point account

Once ruleset conditions are met, SessionM moves customer to next tier level

Customer logs in to get profile and verify promotion to next tier level

Platform Configuration

Before implementing this use case, ensure the following have been configured:

Points

Points account created in environment.

Loyalty Tier System

Point economy with at least two tiers set up, configured with the following behaviors for each tier:

  • Entrance behavior - Set amount of points and limit to particular point account for entering tier.
  • Purchase behavior - Award points per dollar to point account in order to allocate points per purchase.
  • Maintenance behavior - Set to run at regular interval - usually once a day - to ensure tier members can remain in tier.

Note that customers can be part of only one tier level in a tier system.

Sequence Diagram

See the overall flow for this use case below.

CUSTOMER CUSTOMER CLIENT MIDDLEWARE CLIENT MIDDLEWARE SESSIONM SESSIONM CREATE STANDARD OR CUSTOM PROFILE 1 Sign up for loyalty program 2 Create standard and custom profile in default tier level 3 Return standard and custom profile 4 Display standard and custom profile with tier level GET TIER LEVEL PROGRESS AND ADVANCE TO NEXT TIER BASED ON PURCHASES 5 Learn what number of transactions qualify for move to next tier level 6 Get tier level progress 7 Return tier level progress 8 Display that customer needs multiple transactions to move into next tier Purchase transaction steps: Repeat until ruleset satisfied for new tier level 9 Purchase item and finalize transaction 10 Send purchase transaction 11 Enqueue transaction job 12 Return success message 13 Display success message 14 Check transaction against economy ruleset 15 Award customer points outcome 16 Move customer to next tier level when tier ruleset satisfied GET CUSTOMER PROFILE 17 Log in to website or application 18 Get customer profile to show tier level 19 Return customer profile 20 Display customer profile, with new tier level status

Alternative Path

In the diagram above, step 15 adds points to the customer's account based on logic configured in the tier rule set that triggers an award of points when a purchase is made. But another option is to sidestep such logic, especially if a different system is calculating points, and simply deposit points into the account directly using this endpoint, detailed in the UserPoints API documentation: POST /api/1.0/user_points/deposit.

Tasks

This use case diagram contains multiple tasks, each one depicted in its own color-coded section. For more information, see the overview below.

  1. Create Standard and Custom Profile (Use Case Events #1 - #4)

    Discusses how to create customer profiles.

  2. Get Tier Level Progress and Advance to Next Tier Based on Purchases (Use Case Events #5 - #16)

    Provides details that allow customer to learn about advancing to next tier and then making necessary purchases for that advancement.

  3. Get Customer Profile (Use Case Events #17 - #20)

    Provides configurable way to get view of customer's profile data.

Take Note

Information about a customer's tier and progress can be obtained using the Standard Profile API (for basic tier in primary system) or the Custom Profile API (for tiers in all systems). These operations are detailed in the task, Get Customer Profile. Note that if you use the endpoint to retrieve the combined profile (standard/custom) in order to see data for all tiers and systems, you'll need to set the additional parameters detailed in the "API Endpoint Constraints" section of the Get Customer Profile task article.

Best Practices

Consider setting limits on earning frequencies. For example, customers being allowed to make up to 3 transactions a day or 45 transactions in a month to prevent fraud.

Consider using rolling point expiration policies to govern the point accounts.

With respect to tier maintenance:

  • Can take several days to run.

  • Drops customers from one tier to a lower tier. Tier level of a customer drops only when tier maintenance is run.

  • Other behaviors and associated outcomes may be scheduled to run at the same time maintenance processes are set up to run. This overlap of having two or more behaviors working on the same data at the same time may cause unexpected results. Best to avoid potential race conditions during maintenance.

When ranking outcomes designated for behaviors, bear in mind that the rank controls when the outcome starts. When rankings control a subsequent outcome, it runs after the previous, higher-ranked outcome begins, not after the previous outcome finishes.